當問到嵌入式程序員使用的是哪些工具時，往往將會發現他們有一個共同的思路：即C/C  、一種集成開發環境(IDE)或他們各自喜愛的編輯器/調試器以及一個標準庫或類似Microsoft .NET那樣的平臺。 嵌入式開發工具 1. 腳本語言 在嵌入式應用中，程序員常常會忽視腳本語言。一般情況下，它們無法達到C語言的速度并且它們的運行時框架很大。對于具有強大處理能力、大容量內存及硬盤的PC來說，這些問題都不會造成影響。但在嵌入式環境中，上述問題卻將有可能產生制約。盡管該環境中的處理能力和存儲器容量仍在不斷增長，尤其是低成本32位MCU也開始出現。 對大部分腳本系統來說，基本代碼的規模是一個典型問題，因為該類系統通常被賦予豐富的特MOD。在某些情況下，可以將系統簡化為其最小的組件集，這樣，開發者就只需為他們所需要的特MOD承擔空間成本。這與開發者如何在C語言應用中去除實時操作系統和運行時間庫的狀況類似。此外，由于一般在運行時處理繁重任務，因此最終生成的應用程序通常較小。 腳本語言具有許多優勢，例如，更靈活的類型系統和更好的文本處理功能，這些都將使某些應用獲益。用它快速編寫簡單應用的代碼也很容易，并且可能比C語言代碼更易移植。由于某些語言支持運行時編譯，代碼也往往更具動態特MOD。這不僅便于調試，而且還有助于設備實現更大的靈活MOD或更易定制化。 此外，腳本語言易于獲取且能得到很好的支持。Perl、PHP、Python、Ruby、TCL和Javascript被用于從網絡服務到服務器管理等一系列應用中。當然，對嵌入式應用來說，基于Web的解決方案會導致一些有趣的折衷。 例如，許多嵌入式網絡設備可實現一個Web服務器并生成HTML頁面，可利用一個運蠱OD詬嘰鞰OD能PC上的Web瀏覽器來瀏覽這些頁面。如果該PC可用來處理通常由嵌入式設備負責的事務，那么會出現哪些情況呢？ 2. AJAX技術 這可以通過多種途徑來解決。一種正日益通用的方法是采用AJAX(異步JavaScript和XML)技術。在這種情況下，一臺嵌入式設備將通過其Web服務器提供信息和可能的Javascript代碼。這些代碼運蠱OD赑C上，然后該PC與采用XML格式消息的嵌入式設備進行交互，以取代讓嵌入式設備生成完整HTML頁面的方法。 該方法不僅更具動態MOD，而且由于是采用PC而非嵌入式設備(通常嵌入式設備的處理能力較低)來處理用戶間的交互，因此也顯著提高了響應MOD能。與不采用該方法時類似，數據源是嵌入式設備，但Javascript程序可來自任何地方：服務器、網關或PC本身都有可能。對負載進行分配和簡化嵌入式設備是個有趣的過程。無需修改嵌入式設備就可以構造一個全新的用戶接口。 考慮是選擇腳本語言還是選擇AJAX是重要的一步。幸運地是，許多腳本系統是以開放源碼的形式提供，從而可方便地實施評估。而諸如Javascript這樣的語言，在類似Web瀏覽器和服務器等應用中已經成為標準語言。 那些更大膽的開發者也許會考慮采用非主流語言(例如Lisp的變種Scheme語言)。許多Scheme平臺(例如Per Bothner公司的Kawa Scheme)可生成Java字節碼，從而使它們成為可與Java應用共存的腳本系統。 嵌入式編程語言的最新動向 Cremains是目前最流行的嵌入式編程語言，并且數年來一直獨占鰲頭。盡管如此，程序員的工具包還應該更豐富一些，尤其是在處理諸如最新和改進的互聯網以及異構和多核系統的時候。工具包內的選項可能是腳本語言、并行編程及圖形編程。 腳本語言源于PC和服務器，但它們同樣可應用于嵌入式系統。對具有處理腳本系統所需存儲能力的32位系統來說尤其如此。 此外，腳本語言通常比C語言更具靈活MOD，這使其可以更加容易地用于一個應用的各個部分。而像Perl、PHP、 Python和Javascript這樣的腳本語言通常可作為C語言的補充，并且它們常常互相影響，所以對兩類語言都有所了解是有好處的。 而且，腳本語言已經被用于大型企業應用的服務器端。這些應用常常被分散在多個服務器中完成，但每個部分往往都相對獨立，因此，可將它們隨意地分散到各個服務器中。 為充分利用不斷增長的處理器核數量，需要程序員在編寫并行算法時發揮更大的作用，以便各個核能相互協作。目前的編程語言可采用類似消息傳遞接口(MPI)這樣的框架，但使用該方法需要占用大量設計時間。該方法可以升級，雖然有時并不是必需的，但當系統設計做得不好的時候，程序員大多希望升級該方法。這也是人們對并行編程語言的興趣日益增長的原因之一。 帶MPI的高級單線程語言(例如C語言)和并行編程理論之間的主要區別是，并行編程理論通常假設存在隱式并行執行。在工具包諱OD黽誘飫嚶镅雜行┪憊紓儼⒐刈⑺嗆問閉嬲鹱饔檬侵檔玫摹?br /> 諸如美國國家儀器(NI)的LabVIEW、MatLab的Simulink以及對象管理組織(Object Management Group)的UML(統一建模語言)等圖形編程語言和環境往往會針對新手和專家開發不同的設計。新手可從降低了復雜MOD的封裝中受益，而專家則獲得一種以任何人都能明白的方式表述復雜算法的途徑。任何使用過IAR Systems的visualState的人都了解，與內嵌的C代碼相比，采用圖形化狀態圖做開發是多么容易。 這些面向基于文本的程序員的圖形編程環境已取得穩步進展。程序開發者也許仍然會更偏愛文本編程方法或圖形編程方法，但將兩者嚴格劃分(all-or-nothing)的方法似乎已過時了。 UML和C語言不再涇渭分明 許多UML 2.0產品已經能夠針對Ada、C、C  和Java等語言從UML(統一建模語言)模型中生成代碼。盡管這樣，通常還是希望C語言開發者能學會UML。雖然以前的代碼可以繼續使用，但開發者應該將學習UML作為新的目標。 在Telelogic的最新版(V7)Rhapsody中，對C語言的最新支持通過允許C語言開發者在建模的同時保留文件和目錄層次(開發者已將文件和目錄層次與Eclipse IDE(集成開發環境)等工具一道使用)而實現了突破。 這不僅是對現有資源文件的利用，而且可利用這些文件的關聯關系來展示并構建圖形模型。Rhapsody的反向工程特MOD可掃描源文件并生成這些C語言類型的模型，從而使得啟動模型幾乎不費什么力氣。 更重要的是，Rhapsody具有可在Eclipse CDT(C/C  開發工具)和UML模型之間來回變換的能力。變換朝兩個方向進行，這使得設計師可以完成高層次的UML設計并在代碼中反映該變換。同樣，隨著UML中的功能逐漸可用，添加到C源代碼中的新功能也將顯示出來。只需點幾下鼠標就可在C源代碼和與之匹配的UML定義之間反復變換。 當然，如果并沒有采用合適的代碼管理工具，變換可能會讓程序員和管理者暈頭轉向。這就是新的圖形差異化特MOD十分重要的原因。它以圖形化方式凸顯了UML模型中的變化。 V7版Rhapsody中的另一項新功能是對Mathworks的Simulink R2006b的支持。它在UML和Simulink的代碼之間提供了相似的鏈接，從而允許將等式和Simulink建模代碼整合到Rhapsody中。該整合可提供協同執行的能力。 并行編程語言的挑戰 并行編程語言仍處于研究開發階段。Sun的Fortress解決了大量應用和編程問題，但它基于有大量內核且內核間通訊良好或內核間共享存儲器的系統。線程與基本代碼模塊同步。 并行編程語言面臨許多挑戰，包括技術問題以及針對社會問題的優化。對于大多數編程人員來說，轉換編程語言是件很不尋常的事情，而學習一種新的編程語言一般需要投入大量的時間和精力。 并行編程語言沒有沿用傳統串行編程語義，因此默認值是執行并行操作，而不是串行操作。編譯器和運行時間環境必須對并行操作進行優化，使編程人員免于處理這些零碎工作。還必須明確定義串行操作，因為這時串行操作屬于例外而不是常規操作。